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(54) Method and system for negotiating telecommunication resources 



(57) Current telecommunication service providers 
allow users to choose from a small selection of telecom- 
munication services with predetermined performance 
parameters and prices. The invention provides a system 
in which service providers and users negotiate the pa- 
rameters and prices of telecommunication services in 
real time, allowing the service providers and users to 
establish communications that better optimise their 



available resources and current needs. This is done by 
having software agents that represent each concerned 
party, negotiate the terms of the communication in real 
time. Further, the invention allows third parties to create 
new agent or negotiating discipline software available 
over the Internet, which will allow the technology to ma- 
ture quickly, and to respond to new services and/or re- 
quirements. 
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Description 

[0001] The present invention relates generally to tel- 
ecommunications, and more specifically, to a method 
and system of negotiating resources over telecommu- 5 
nication networks offering a variety of services. 

Background of the Invention 

[0002] For a long time, telecommunication networks 10 
were comprised of single Service Providers making a 
single service available to Users. However, telecommu- 
nication networks have evolved greatly over the last two 
decades and continue to evolve, so that there are cur- 
rently multiple providers offering multiple services on '5 
multiple levels. For example, data transmission meth- 
ods and protocols now include Internet Protocol (IP), 
asynchronous transfer mode (ATM), frame relay, and 
digital telephony. Similarly, in the long distance voice tel- 
ephone market there a large number of Service Provid- 20 
ers who use various transmission means including an- 
alogue, digital and digital compression methods, over 
hard wire, wireless, fibre optic and satellite transmission 
means. The networks of these Service Providers are in- 
terconnected with others to form larger heterogeneous 25 
networks. 

[0003] Determining the optimal means of communi- 
cating between two points over such telecommunication 
networks is a complex task, requiring consideration for 
the price, quality and availability of services, in view of 30 
the requirements of the communication desired. Pres- 
ently, there is no system available which allows the op- 
timal means of communication to be determined. At- 
tempts have been made to provide a solution for ATM 
and IP networks, but those attempts are fundamentally 35 
flawed for reasons that will be described herein after. 
[0004] It is also desirable that such a system allow op- 
timisation in view of the conflicting requirements of Us- 
ers and Network Service Providers in a dynamic way. 
This is particularly important for communication links *o 
with limited bandwidth, such as wireless communica- 
tions. Again, no such system is available. 
[0005] A telecommunication network may be de- 
scribed as a physically distributed collection of nodes 
interconnected by links. Examples of end-nodes are Us- *5 
er Interfaces such as telephones or personal computers 
which produce and consume data. Intermediate nodes 
such as switches, routers or gateways generally transfer 
data from an incoming link to an outgoing link, while 
some may process or store data to offer services such so 
as conferencing or voicemail. 

[0006] Voice and computer data were once carried on 
separate networks, although both are now generally 
transmitted digitally. Becausethe requirements for voice 
and data transmission are so different, it is difficult to 55 
optimize the provision of both on * oommon network. 
Voice communication, for example, produces a steady 
stream of data at a fairly low rate, and rapid delivery is 



more important than accuracy. In contrast, data applica- 
tions such as Web browsing generally produce bursts 
of data that are to be delivered accurately, and for which 
a delay of a second or two may be considered accept- 
able. 

[0007] Other services may have different require- 
ments for accuracy, delay and data rate, which charac- 
terise the Quality of Service (QoS) in a communication 
session. Ideally, a telecommunication Service Provider 
should provide a service which optimises communica- 
tion for a User's particular application and simultaneous- 
ly optimises the provision of that service over his own 
network along with services he is providing to other Us- 
ers. Using traditional techniques, this would require the 
Service Provider to offer a different Quality of Service 
for each new application of data communications that is 
developed. No telecommunication system is currently 
available that accommodates such optimisation in view 
of the differing QoS requirements of various Users and 
applications. 

[0008] It is desirable to provide a single telecommu- 
nications network which carries both data and voice on 
a common physical channel. This reduces costs by 
sharing resources. It follows that new applications must 
be able to use these integrated networks so that they 
can be developed without the overhead of creating spe- 
cial telecommunications networks for them. 
[0009] It is also desirable that the process of develop- 
ing new applications be as open as possible, rather than 
restricted to a small group of developers with special- 
ized knowledge or who can be trusted to allocate re- 
sources according to policy, so that new applications 
can emerge quickly. 

[0010] Because Service Providers have limited 
knowledge of what applications their Users may be im- 
plementing, it is difficult for them to offer products which 
are tailored to those applications. It is also clearly im- 
possible for Service Providers to anticipate the require- 
ments of applications that have yet to be developed. 
Similarly, Service Providers are not generally aware of 
the computing power that a given User has, in terms of 
processing speed, memory capacity, software and op- 
erator expertise. Therefore, Service Providers generally 
provide products that serve the most common market, 
and possibly one or two major niche markets. Currently, 
Users must search for the Service Provider that offers 
products best suited to their needs, if one does exist. 
Users that have multiple needs may have to enlist the 
services of a number of Service Providers. 
[0011] A conventional telephony network provides a 
fixed quality of voice service, called toll quality, at a pre- 
arranged price. Long-distance re-sellers may use digital 
voice compression to offer lower-cost long distance 
service at a reduced price, but again, this service offers 
a fixed quality at a pre-arranged price. Because com- 
petitors offer different voice quality, pricing and proba- 
bility of call success, End Users can choose to pay for 
quality by selecting a more expensive Service Provider 
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with a good reputation. This method becomes cumber- 
some when new services appear and the end user must 
select a Service Provider for each of his applications and 
track their reputations by word of mouth. 
[0012] When there is contention for network resourc- 
es, the conventional telephone systems generally take 
a "first-come-first-served" approach and deny services 
to callers if sufficient resources are not available. This 
process is known as call admission. Clearly, there may 
be instances where a User would rather accept a lower 
quality communication than be denied access. The cur- 
rent telecommunications networks can not provide such 
an option. 

[0013] The Internet has traditionally offered "best ef- 
fort" service without making any attempt to prioritize traf- 
fic. However, because each Service Provider may make 
different choices about its network capacity and connec- 
tions to other Service Providers, End Users may have 
some freedom to trade off quality for cost indirectly by 
choosing to subscribe through a variety of Service Pro- 
viders. However, this is not a flexible or rigorous solu- 
tion. 

[0014] Packet switching systems such as the Internet, 
can assign different priorities to different packets so that 
high-priority packets take precedence over low-priority 
ones when there is a conflict. The difficulty is to assign 
the priorities correctly in a large system with many com- 
peting demands. 

[0015] Packet priorities are not usually implemented 
to give a simple precedence because high-volume traf- 
fic flows at high priorities will completely shut out even 
low volumes of data at lower priorities. Fairness criteria 
are therefore used to define the effects of priorities, with 
a particular algorithm called weight fair queuing imple- 
mented in Internet routers. It rotates access to network 
links among the priority queues with the effect that light- 
ly-populated priority queues get preferential but not ex- 
clusive access. However, this approach still does not de- 
fine how to set packet priorities. 
[0016] Recent extensions of the Internet protocol al- 
low users to specify, by setting certain bits in their packet 
headers, that their data is to be routed to minimize cost 
or to minimize delay. These mechanisms are rarely 
used, however, because no mechanism is specified to 
ensure that they are used sparingly. Users are given no 
reason to demand anything but least cost and least de- 
lay in every case, so that the request becomes mean- 
ingless. The mechanism is also very coarse, allowing 
Users only two levels of concern about cost, and includ- 
ing no mechanism by which the User can state the rate 
at which he expects to produce data. 
[0017] The ATM standard provides more detailed 
mechanisms to express Quality of Service parameters. 
It allows average and maximum delays to be specified 
and reported, and allows maximum and minimum data 
rates to be specified. These mechanisms are also rarely 
used, because again Users are given no reason to mod- 
erate their demands. ATM Quality of Service mecha- 



nisms are therefore adapted to closed telecommunica- 
tions systems in which parameters that affect User traf- 
fic are set by the Service Provider. 
[0018] Policy-based routing is a system that allows 
5 the network administrator to define priorities based on 
variables such as the source and destination, or protocol 
being used. For example, web browser traffic using hy- 
pertext traffic protocol (http), could be assigned a higher 
priority than email traffic using standard mail transfer 
10 protocol (smtp). 

[0019] Often, Internet communications result in a 
packet passing through several different networks. Gen- 
erally, each network will be administered by a different 
entity, with different and uncoordinated policies. There- 
fore, each of the Internet strategies described above 
does not offer a practical solution, as packets will inev- 
itably pass through bottlenecks created by these unco- 
ordinated policies. 

[0020] Even if these policies were to be coordinated, 
or the transmission was to be made through a single 
Service Provider, the User still has noway of negotiating 
the treatment that his data is to receive within the net- 
work. 

[0021] The existing systems do not allow provision of 
diverse services with specific performance require- 
ments. For example, remote surgery in which a physi- 
cian uses a remote manipulator to perform surgery, 
could not be implemented with existing systems. This 
application would require very strict demands on both 
accuracy and timeliness together with a high bandwidth 
for video. The consequences of the network failing to 
perform as required would be very serious. 
[0022] Another example is Internet gaming, in which 
a number of players exchange small packets of infor- 
mation to update each other on their moves. Given how 
such games are typically implemented, this application 
calls for low latencies, but bandwidth requirements are 
light and a fairly high rate of packet loss can be tolerated; 
such game applications are generally designed to toler- 
ate these packet losses. 

[0023] It is also clear that the remote surgery applica- 
tion should take priority over Internet gaming when there 
is contention . Therefore, there is a need for a systematic 
way of making these decisions for the interaction among 
a wide variety of applications. 

[0024] There is therefore a need for flexible system 
for resolving contention for telecommunications network 
resources that provides an improvement on the prob- 
lems outlined above. 

Summary of the Invention 

[0025] It is therefore an object of the invention to pro- 
vide a method and system for negotiating telecommu- 
nication resources. 

[0026] One aspect of the invention is broadly defined 

as a telecommunications system comprising: a First Us- 
er Interface; a Second User Interface; a telecommuni- 
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cations network interconnecting the First User Interface 
with the Second User Interface and having at least one 
transmission means and protocol; the First User Inter- 
face having a First User Agent, representing the inter- 
ests of the First User Interface in negotiating communi- 
cation between the First User Interface and the Second 
User Interface; the telecommunications network being 
administered by a Network Agent, representing the in- 
terests of the telecommunications network in negotiat- 
ing communication between the First User Interface and 
the Second User Interface; and a Negotiation Manager 
being operable to: identify participants in a negotiation; 
implement a negotiation discipline which allows each 
participant to consider a contract and either accept or 
revise the contract; and respond to the negotiation being 
successful by executing the contract. 
[0027] In another embodiment of the invention there 
is provided a method of establishing communication be- 
tween a First User and a Second User, said First User 
and said Second User being interconnected by a tele- 
communications network having at least one transmis- 
sion means and protocol, comprising the steps execut- 
ed by a Negotiation Manager of: identifying participants 
in a negotiation; implementing a negotiation discipline 
which allows each said participant to consider a contract 
and either accept or revise said contract; and respond- 
ing to said negotiation being successful by executing 
said contract. 

[0028] In another embodiment of the invention there 
is provided a method of establishing communication be- 
tween a First User and a Second User, said First User 
and said Second User being interconnected by a tele- 
communications network having at least one transmis- 
sion means and protocol, said at least one transmission 
means and protocol being administered by a Network 
Entity, said method comprising the steps executed by 
said Network Entity of: receiving a contract from a Ne- 
gotiation Manager; inspecting said contract; responding 
to said contract not being acceptable by modifying said 
contract to an acceptable state; and returning said con- 
tract to said Manager. 

[0029] In a further embodiment of the invention there 
is provided a method of establishing communication be- 
tween a First User and a Second User, said First User 
and said Second User being interconnected by a tele- 
communications network having at least one transmis- 
sion means and protocol, comprising the steps execut- 
ed by said First User of: receiving a contract from a Ne- 
gotiation Manager; inspecting said contract; responding 
to said contract not being acceptable by modifying said 
contract to an acceptable state; and returning said con- 
tract to said Negotiation Manager. 
[0030] In accordance with a first aspect of the inven- 
tion, there is provided a telecommunication system 
comprising: 

a first user interface and a second user interface 
interconnected by a telecommunications network; 



said first user interface being connected to means 
for executing a first set of programming code that 
determines said first user interface's requirements 
for communicating with said second user interface) ; 
5 said telecommunication network being connected 
to means for executing a second set of program- 
ming code that determines available network re- 
sources of said network; the system comprising 
means for determining terms of communication 
*0 said telecommunication network being connected 
to means for executing a second set of program- 
ming code that determines available network re- 
sources of said network; the system comprising 
means for determining terms of communication be- 
'5 tween said first user interface and said second user 
interface through said network; 

characterised in that said means for executing 
said first and second sets of programming code com- 
prises at least one computer processor and electronic 
memory means, said at least one computer processor 
and electronic memory means being operable to exe- 
cute a third set of programming code that manages ne- 
gotiations between said first set of programming code 
and said second set of programming code, said negoti- 
ations being for determining said terms of communica- 
tion between said first user interface and said second 
user interface through said network and being based on 
a trusted negotiating discipline. 
[0031] In a particular implementation of the first as- 
pect, the trusted negotiating discipline is selectable by 
a user of the first user interface from a plurality of nego- 
tiating disciplines. 

[0032] In a particular implementation of the first as- 
pect, the requirements include the available hardware 
resources of the first user interface. 
[0033] In a particular implementation of the first as- 
pect, the requirements include the network resources 
needed by an application executing on the first user in- 
terface. 

[0034] In a particular implementation of the first as- 
pect, the application is voice telephony. 
[0035] In a particular implementation of the first as- 
pect, the requirements include the costs that are to be 
assessed to the first user interface during the commu- 
nication. 

[0036] In a particular implementation of the first as- 
pect, the available network resources include presently 
available network resources. 

[0037] In a particular implementation of the first as- 
pect, the available network resources include a cost of 
the network resources to be consumed during the com- 
munication. 

[0038] In a particular implementation of the first as- 
pect, the available network resources include a predic- 
tion of network usage during the communication. 
[0039] In a particular implementation of the first as- 
pect, the first set of programming code is implemented 
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using a software agent that is programmed with instruc- 
tions that represent the interests of the first user inter- 
face. 

[0040] In a particular implementation of the first as- 
pect, the third set of programming code is implemented 
as a negotiation manager software agent. 
[0041] In a particular implementation of the first as- 
pect, the second set programming code is implemented 
as a single network software agent. 
[0042] In a particular implementation of the first as- 
pect, the second set of programming code is implement- 
ed as multiple network software agents, each network 
software agent being respective to a different telecom- 
munication service provider. 

[0043] In a particular implementation of the first as- 
pect, the second user interface is connected to a com- 
puter processor and an electronic memory means for 
executing a fourth set of programming code, preferably 
implemented as a software agent, that determines the 
second user interface's requirements for communicat- 
ing with the first user interface. In this particular imple- 
mentation, the third set of programming code is for fur- 
ther managing the negotiations so as to include the 
fourth set of programming code therewith. The require- 
ments can include the available hardware resources of 
the second user interface. Alternatively, or in addition, 
the requirements include the network resources needed 
by an application executing on the second user inter- 
face. Alternatively, or in addition, the requirements in- 
clude the costs that are to be assessed to the second 
user interface during the communication. The applica- 
tion can be, for example, voice telephony. 
[0044] In a particular implementation of the first as- 
pect, the network is an ATM network. 
[0045] In a particular implementation of the first as- 
pect, the trusted negotiating discipline includes at least 
one of a round robin, bid-and-ask, bluffing, poker and a 
reverse auction. 

[0046] In a particular implementation of the first as- 
pect, the negotiating discipline terminates the negotia- 
tion if the negotiations fail to reach an agreement within 
a predetermined period of time. 
[0047] In accordance with a second aspect of the in- 
vention, there is provided a computer-implemented 
method for negotiating terms of communication be- 
tween a first user interface and a second user interface 
connected by a telecommunications network, said 
method comprising the steps of: 

receiving, from a first set of programming code as- 
sociated with said first user interface, an offer for 
said terms of communication, said first user inter- 
face's offer including said first user interface's re- 
quirements for communicating with said second us- 
er interface through said network; 
presenting said first user interface's offer to a sec- 
ond set of programming code associated with said 
network; 



receiving, from said second set of programming 
code, another offer for said terms of communica- 
tion, said another offer including at least said net- 
work's available resources for said communication 
5 and including a modification of said first user inter- 
face's offer; 

characterised by the step of: 

10 verifying said first user interface's offer conforms 
with a trusted negotiation discipline; wherein said 
step of presenting said first user interface's offer to 
said second set of programming code is only carried 
out if said first user interface's offer confirmer with 

15 aid discipline; and the further steps of: 

returning said another offer to said first set of pro- 
gramming code if said another offer conforms with 
said discipline; 

repeating the foregoing steps if said offers conform 
20 with said discipline; and, 

terminating said negotiating if any one of said offers 
and counteroffers fail to converge according to said 
negotiation discipline. 

25 [0048] In a particular implementation of the second 
aspect, the trusted negotiating discipline is selectable 
by a user of the first user interface from a plurality of 
negotiating disciplines. 

[0049] In particular implementation of the second as- 

30 pect, the requirements include the available hardware 
resources of the first user interface. 
[0050] In accordance with another aspect of the 
present invention, there is provided a user-interface as 
claimed in claim 1 . 

35 [0051] In accordance with another aspect of the 
present invention, there is provided a telecommunica- 
tion network as claimed in claim 5. 
[0052] In accordance with another aspect of the 
present invention, there is provided a computer-imple- 

40 mented method for negotiating terms of communication 
between a first user interface and a second user inter- 
face connected by a telecommunications netowrk, the 
method being as claimed in claim 12. 
[0053] Optional and preferred features of the aspects 

45 of the Invention defined in claims 1 , 5, 8 and 12 are set 
out in claims 2-4, 6, 7, 9-11 and 13. 

Brief Description of the Drawings 

so [0054] These and other features of the invention will 
become more apparent from the following description in 
which reference is made to the appended drawings in 
which: 

55 Figure 1 presents a physical layout of a telecom- 
munications system in a manner of the invention; 
Figure 2 presents a schematic diagram of the soft- 
ware layer of a telecommunications system in a 
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manner of the invention; 

Figure 3 presents a flow chart of a method for im- 
plementing a Negotiation Manager for negotiating 
communication between a First User and a Second 
User in a manner of the invention; 
Figure 4 presents a flow chart of a method for im- 
plementing a Telecommunication Network's Agent 
for negotiating communication between a First User 
and a Second User in a manner of the invention; 
Figure 5 presents a flow chart of a method for im- 
plementing a First User's Agent for negotiating com- 
munication between a First User and a Second User 
in a manner of the invention; 
Figure 6 presents a flow chart of a preferred meth- 
od for implementing a Negotiation Manager for ne- 
gotiating communication between a First User and 
a Second User in a manner of the invention; 
Figure 7 presents a flow chart of a preferred nego- 
tiating discipline for establishing terms of communi- 
cation between a First User and a Second User in 
a manner of the invention; 

Figure 8 presents a flow chart of a preferred meth- 
od for implementing a Telecommunication Net- 
work's Agent for negotiating terms of communica- 
tion between a First User and a Second User in a 
manner of the invention; and 
Figure 9 presents a flow chart of a preferred meth- 
od for implementing a First User's Agent for nego- 
tiating terms of communication between a First Us- 
er and a Second User in a manner of the invention. 

Detailed Description of Preferred Embodiments of 
the Invention 

[0055] A system which addresses the objects outlined 
above, is presented as a block diagram in Figure 1. 
Physically, this telecommunication system 10 consists 
of a First User Interface 12 and a Second User Interface 
14, interconnected by a telecommunications network 
16. The First User Interface 12 and Second User Inter- 
face 14 may be, for example, telephones, cellular tele- 
phones, personal digital assistants, personal computers 
or servers which produce and consume data. -The tel- 
ecommunications network 16 has at least one transmis- 
sion means and protocol, which will be described in de- 
tail hereinafter. 

[0056] At the software layer, the First User Interface 
12 will have a First User Agent 18 which represents the 
interests of the First User Interface 12 in negotiating a 
communication between itself and the Second User In- 
terface 14. Similarly, the telecommunications network 
16 has a telecommunications network agent 20 which 
represents the interests of the telecommunications net- 
work 16 in negotiating the communication. 
[0057] The negotiation of the terms of communication 
may be administered by a software agent called the Ne- 
gotiation Manager 22. Physically, the Negotiation Man- 
ager 22 may reside anywhere in the system 10, though 



in a simple implementation, it will reside somewhere in 
the telecommunications network 16 provided by the 
First User's Service Provider. 

[0058] The Negotiation Manager 22 is operable to: 

5 

1 . identify participating agents in a negotiation; 

2. implement a negotiation discipline which allows 
each participating agent to consider a contract and 
either accept or revise the contract; and 

io 3. respond to the negotiation being successful by 
executing the contract. 

[0059] Broadly speaking, this system 10 provides a 
flexible telecommunications system for resolving con- 
15 tention for network resources. 

[0060] The system 10 is flexible in that new services 
and features developed by outside parties may be im- 
plemented in the negotiation. In current telecommuni- 
cation systems, all services are provided and controlled 
by the telecommunication system providers, which lim- 
its the services available and impedes the provision of 
new services. In this system 10, an End User, Negotia- 
tion Manager or other Network Entity with an interest in 
the negotiation, may obtain new negotiating disciplines 
or software agents developed by themselves or outside 
parties and implement them in the negotiation. Details 
of such options will be described in greater detail herein 
after. 

[0061] The system 10 of the invention may also be 
generalised to permit multiple parties to negotiate the 
terms of a given communication. The requirement for 
this functionality is clear, as a communication may have 
to pass through two, three or more telecommunication 
providers in traversing a broad geographical area, it is 
in the best interest of all the Network Entities involved 
in the communication to also participate in the negotia- 
tion. 

[0062] This generalisation also allows communica- 
tions which have multiple End Users, such as confer- 
ence calls, to be negotiated with all of the End Users 
and their associated Service Providers participating. 
[0063] The system 10 of the invention encourages 
Service Providers to offer a greater variety and flexibility 
in their services, by improving the efficiency of their net- 
works accordingly. In turn, this increased variety and 
flexibility allows the User to negotiate the services that 
he wants, rather than being forced to choose between 
limited services from the Service Provider to which he 
subscribes, or having to seek out a new Service Provid- 
er that offers the services he requires. 
[0064] This system 1 0 resolves of contention between 
Users by making a variety of data and voice telecom- 
munication services available that are suited to varying 
applications, and providing incentives, such as reduced 
prices, to use available resources rather than insisting 
on the highest quality. By making the provision of those 
services open to real time negotiation, the participants 
are able to reach a mutually agreeable result. 
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[0065] As described above, the invention allows these 
improvements by providing a system wherein each in- 
terested party has a software agent which negotiates on 
his behalf. As a minor issue, this requires that a conven- 
tion for negotiation be established that all the software 
agents can understand, though the nature and param- 
eters of such a convention does not limit the invention. 
[0066] A generalization of the software layer of the in- 
vention is presented in Figure 2. This Figure identifies 
each interested party in the negotiation as a participant 
24. In a simple implementation as described with re- 
spect to Figure 1 above, the participants 24 would in- 
clude the First User's Agent 18 and the Telecommuni- 
cation Network's Agent 20. This example is consistent 
with the traditional model of a voice telecommunication 
where the originating caller assumes the cost of the 
service. 

[0067] However, having an Agent representing the 
Second User involved in the negotiation would allow the 
Second User to assume all or part of the cost of the tel- 
ecommunication. More importantly, it would allow the 
communication to be negotiated with consideration for 
the interests of the Second User Interface 14. The Sec- 
ond User Interface 14, for example, may not have the 
modem speed of the First User Interface 12, so there 
may not be any benefit to negotiating a high-speed con- 
nection between the First User Interface 12 and the Tel- 
ecommunication Network 16. 

[0068] Similarly, if the Telecommunication Network 16 
consists of a number of ATM, long distance or frame re- 
lay providers, it may be advantageous to include a soft- 
ware agent for each respective telecommunication pro- 
vider in the negotiation as well. Therefore, any network 
entity in the telecommunication system 10 which has an 
interest in the outcome of the negotiation, may be a par- 
ticipant 24 in the negotiation. 

[0069] The Participants 24 communicate with the Ne- 
gotiation Manager 22 by passing a Contract 26 back and 
forth using standard default communications protocols. 
In general, a negotiation will consist of a single Contract 
26 that each participant 24 is free to inspect and modify, 
while in use of some disciplines, the Contract 26 may 
also contain parts of the communication content. Use of 
a single Contract 26 avoids problems usually experi- 
enced with multiple contracts that require additional 
overheads of coordination and time stamping. 
[0070] As well, because the Contract 26 is a relatively 
small data packet, little real time is lost in transferring it 
from one participant 24 to another. The User may also 
have some control over the Contract's 26 size by his 
choice of negotiating strategy and parameters. The con- 
tents of this Contract 26 will be detailed herein below. 
[0071] The Negotiation Manager 22 will employ a ne- 
gotiation discipline 28 according to a set of discipline 
parameters 30. The invention will be described herein 
below with respect to a specific example of a negotiation 
discipline 28, but the invention Is Independent of the ac- 
tual negotiation discipline 28 employed. 



[0072] As noted above, the invention is not limited by 
the physical location of the Negotiation Manager 22. In 
general, it is desirable that the Negotiation Manager 22 
be trusted" by all parties, or reside in a secure location, 
5 but even this is not necessary if participants 24 secure 
themselves within their negotiating preferences. For ex- 
ample, a participant 24 could restrain his contract 26 
proposals to be revocable, allowing himself a last-look 
prior to commencing execution of a negotiated contract 
26. Other methods of securing, for example, by use of 
cryptographic signatures or an authentication list, are 
known in the art. 

[0073] Because the location of the Negotiation Man- 
ager 22 is not restricted, it could be provided by a net- 
work Service Provider, the User himself, or a third party. 
This flexibility is one of the benefits of the invention, in 
that it makes this an open system. A third party can cre- 
ate a Negotiation Manager 22 or a negotiation discipline 
28 and make it available to all Users and Network Enti- 
ties on the telecommunication system 10. 
[0074] This openness will allow the system 10 of the 
invention to mature very quickly by the addition of new 
Negotiation Managers 22 and negotiating disciplines 28 
with new features. Traditional telecommunication sys- 
tems which were limited to a single Service Provider 
would only offer the services that the single provider 
made available. 

[0075] A simple flow chart of the Negotiation Manager 
22 operation is presented in Figure 3. The Negotiation 
Manager 22 identifies the participants 24 in the negoti- 
ation at step 32, implements the negotiation discipline 
28 at step 34, and if the negotiation is successful, exe- 
cutes the terms of the contract 26 that have been nego- 
tiated at step 36. 

[0076] The identification of the participants 24 at step 
32 may be made in a number of manners. In a simple 
implementation with two participants 24, namely the 
First User's Agent 18 and the Telecommunication Net- 
work's Agent 20, the participants 24 will be identified in 
the initial contract 26 created by the First User's Agent 
18 when he initiates his request for communication with 
the Second User Interface 14. In such a case, the initial 
contract 26 will identify the First User Interface 12 as the 
source of the contract 26 and the calling party, the Sec- 
ond User Interface 14 as the called party, and the Tele- 
communication Network 16 as the Service Provider. 
[0077] In the more general case, the initial contract 26 
will still identify the First User Interface 12 as the source 
of the contract 26 and the calling party, and the Second 
User Interface 14 as the called party, but the identifica- 
tion of participants 24 at the Telecommunication Net- 
work 16 level may be left to the Negotiation Manager 
22. Having Negotiation Managers 22 identify Service 
Providers from a database will give the Service Provid- 
ers motivation to actively seek out Negotiation Manag- 
ers 22, because if a Service Provider is not on a Nego- 
tiation Manager's 22 database, he will not be advised of 
any negotiations by that Negotiation Manager 22. Meth- 
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ods for creating, accessing and maintaining such a da- 
tabase of Service Providers are well known in the art. 
[0078] Implementation of the negotiation discipline 28 
at step 34 will be described in greater detail with respect 
to the example of the round-robin discipline in Figure 7. 
For the sake of Figure 3, it is sufficient that the negoti- 
ation discipline 28 consist of a strategy which allows a 
contract 26 to be negotiated that is satisfactory to each 
participant 24. In the simple case of Figure 1 , the nego- 
tiation discipline 28 may consist of the Negotiation Man- 
ager 22 transferring the contract 26 back and forth be- 
tween the First User's Agent 18 and the Telecommuni- 
cation Network's Agent 20 without any interference by 
the Negotiation Manager 22. In such a case, the First 
User's Agent 18 may time out if a successful contract 
26 is not negotiated within a specific time period, in order 
to hart the negotiation. 

[0079] If the initial contract 26 prepared by the First 
User's Agent 18 is acceptable to the Telecommunication 
Network's Agent 20, then the Telecommunication Net- 
work Agent 20 may approve the contract 26 and return 
it to Negotiation Manager 22 unmodified. Details on how 
the Telecommunication Network's Agent 20 analyses 
the contract 26 and responds will be described with re- 
spect to Figures 4 and 8 herein below. 
[0080] At step 36, the Negotiation Manager 22 deter- 
mines whether the contract 26 has been successfully 
negotiated, and if so, allows the contract 26 to execute. 
The successful negotiation of the contract 26 may be 
indicated by setting a flag or bit in the contract 26. 
[0081] Figure 4 describes the broad operation of Tel- 
ecommunication Network's Agent 20 in the form of a 
flow chart. As indicated above, the purpose of the Tele- 
communication Network's Agent 20 is to represent the 
interests of the Telecommunication Network 16 in nego- 
tiating a communication between the First User Inter- 
face 12 and the Second User Interface 14. As the Tele- 
communication Network 16 has at least one telecom- 
munication means and protocol at its disposal, it may 
want to negotiate to optimise efficient use of its resourc- 
es. 

[0082] Operation of the Telecommunication Net- 
work's Agent 20 is straightforward. At step 38, the Tel- 
ecommunication Network's Agent 20 receives the con- 
tract 26 from the Negotiation Manager 22. On the first 
iteration of a simple implementation as described with 
respect to Figure 1 above, this contract 26 will contain 
the information supplied by the First User's Agent 18 
and described above. The Telecommunication Net- 
work's Agent 20 inspects the contents of this contract 
26 at step 40, and determines whether it is acceptable 
or not. 

[0083] If the terms of the contract 26 are not accept- 
able, the Telecommunication Network's Agent 20 mod- 
ifies the terms of the contract 26 to terms it would find 
acceptable, and returns the contract 26 to the Negotia- 
tion Manager 22 at step 44. In a simple case where the 
Telecommunication Network 16 has a very limited set of 



resources, the Telecommunication Network's Agent 20 
may comprise a simple algorithm which generates new 
contract 26 terms by referring to a database of resourc- 
es and standard rates. 

5 [0084] In a more sophisticated implementation, the 
Telecommunication Network's Agent 20 may comprise 
a rules-based agent that optimises use of a continuum 
of resources. For example, if the Telecommunication 
Network 16 has access to ATM services, it may offer 

10 Constant Bit Rate (CBR) transmission on a complete 
continuum from 10 Kb/s to 10 Mb/s, with a rate corre- 
sponding linearly to the traffic level. In such an arrange- 
ment, theTelecommunication Network's Agent 20 would 
have to consider its current traffic capacity, load, expect- 

15 ed traffic and cost, in determining a counter offer that 
optimizes use of its resources. The implementation of 
such resource management methods would be within 
the ability of one skilled in the art. 
[0085] If the terms of the contract 26 are determined 

20 to be acceptable at step 40, then the Telecommunication 
Network's Agent 20 indicates its acceptance in the con- 
tract 26 at step 46 and returns it to the Negotiation Man- 
ager 22 at step 44. As noted above, the indication that 
the contract 26 is acceptable may be done in a number 

25 of manners, including setting a flag or bit in the contract 
26. 

[0086] Figure 5 describes the broad operation of First 
User's Agent 20 in the form of a flow chart. This flow 
chart describes a software agent with the functionality 

30 to receive only, but it would be expected that implemen- 
tations would exist which require either originating com- 
munications only, or both receiving and originating. 
[0087] In broad terms, the First User's Agent 18 op- 
erates in a very similar manner to that of the Telecom- 

35 munication Network's Agent 20. As noted above, the 
purpose of the First User's Agent 18 is to represent the 
interests of the First User Interface 12 in negotiating a 
communication between the First User Interface 12 and 
the Second User Interface 14. As the computational and 

^0 communication resources and constraints of the First 
User Interface 12 may only be known to itself, it may 
want to negotiate a communication means and protocol 
that makes best use of its resources in view of the ap- 
plication that it is implementing. For example, these re- 

45 sources and constraints may include processing speed, 
memory capacity and modem speed. 
[0088] Operation of First User's Agent 1 8 commences 
at step 48 when the First User's Agent 18 receives the 
contract 26 from the Negotiation Manager 22. In the 

50 broad implementation , the First User's Agent 1 8 may not 
have the functionality to initiate a communication nego- 
tiation. However, such functionality will be described 
with respect to the preferred embodiment of the inven- 
tion with respect to Figure 9. In the case of the First 

55 User's Agent 1 8 not having the functionality to generate 
a initial contract 26, the initial contract 26 may be gen- 
erated by another party attempting to contact the First 
User Interface 12, or may be generated as a standing 
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order by the Telecommunication Network's Agent 20 
when the First User Interface 1 2 logs on to the Telecom- 
munication Service provided by the Telecommunication 
Network 16. Other similar circumstances would be clear 
to one skilled in the art. 

[0089] The First User's Agent 18 inspects the con- 
tents of this contract 26 at step 50, and determines 
whether it is acceptable or not. If the terms of the con- 
tract 26 are not acceptable, the First User's Agent 18 
modifies the terms of the contract 26 to terms it would 
find acceptable at step 52, and returns the contract 26 
to the Negotiation Manager 22 at step 54. In a simple 
case the First User's Agent 18 may have a predefined 
set of limits that the First User Interface 1 2 does not wish 
to exceed. For example, this may include: not accepting 
charges for any incoming calls, not exceeding the trans- 
mission rate of First User Interface's 12 modem, or not 
accepting voice communication with less than toll qual- 
ity. If the parameter of an incoming contract 26 exceeds 
any of these limitations, they may be identified with a 
simple logic test, and a new contract 26 generated which 
changes these parameters so that they fall within the 
desired bounds. The First User's Agent 18 may com- 
prise a simple algorithm which refers to a database of 
resources and preferences. 

[0090] In a more sophisticated implementation, the 
First User's Agent 18 may comprise a rules-based soft- 
ware agent that optimises use of a continuum of re- 
sources, in the same manner as the Telecommunication 
Network's Agent 20 described above. The First User's 
Agent 18 may, for example, negotiate the communica- 
tion with consideration for the particular application , and 
the computation and communication parameters of the 
First User Interface 12. These preferences may corre- 
spond to end-to-end telecommunication parameters 
such as peak cell rate (PCR), tolerable cell delay varia- 
tion (CVDT), cell transfer delay (CTD), cell loss ratio 
(CLR) and peak-to-peak delay variation (CDV). Such 
parameters are generally used in ATM to specify the 
quality of service (QoS) that a telecommunication serv- 
ice provides. Clearly, the invention may be applied with 
various ones of these parameters, or different parame- 
ters known in the art, such as mean opinion score 
(MOS). Other subject measures are also possible with 
mappings. 

[0091] If the terms of the contract 26 are determined 
to be acceptable at step 50, then the First User's Agent 
18 may indicates its acceptance in the contract 26 at 
step 56 and return it to the Negotiation Manager 22 at 
step 54. As noted above, the indication that the contract 
26 is acceptable, may be done in a number of manners, 
including setting a flag or bit in the contract 26. 
[0092] The implementation of the invention in the pre- 
ferred embodiment will now be described. 
[0093] Figure 6 outlines the preferred operation of the 
Negotiation Manager 22 in response to a communica- 
tion request from a User. At step 88, the Negotiation 
Manager 22 is initialized. It is known in the art of com- 



puter software programming to initialize variables, ar- 
rays and functions at the beginning of a program. At step 
60, the participants 24 in the negotiation are identified. 
If the negotiation has been initiated by a First User, then 

5 the initial contract 26 that the Negotiation Manager 22 
receives will have both the First User Interface 12 and 
Second User Interface 1 4 identified, and the Negotiation 
Manager 22 will have to identify the entities of the Tele- 
communication Network 16 that it wishes to add as par- 

10 ticipants 24 in the negotiation in order to complete the 
communication. 

[0094] The Negotiation Manager 22 then authenti- 
cates the participants 24 at step 62. As noted above, the 
Negotiation Manager 22 is a software agent that may 

is exist anywhere in the network. Therefore, it will not nec- 
essarily have secure relationships with all of the partic- 
ipants 24 in a negotiation. In the preferred embodiment 
the participants 24 will be authenticated by some means 
such as the use of cryptographic signatures as known 

20 in the art. 

[0095] Once the participants 24 have been authenti- 
cated, the Negotiation Manager 22 may set up the en- 
vironment for the discipline 28 at step 64. 
[0096] The participants 24 are then informed that the 

25 negotiation is about to start at step 66. This step pro- 
vides participants 24 with feedback as to the state of the 
negotiation, but also may be used to caution participants 
24 that subsequent proposals may be non-revocable. 
That is, once a user has made an offer, he is not able to 

30 withdraw his offer. Preferably, the non-revocability will 
time out after a short period of time, such as a minute. 
[0097] The negotiation discipline 28 is then imple- 
mented at step 68. Greater details as to the operation 
of the negotiation discipline 28 are provided hereinafter 

35 with respect to Figure 7. 

[0098] The participants 24 are then advised whether 
the negotiation was successful or failed, at step 70. If 
the negotiation is identified as being successful at step 
72, then the contract 26 is executed at step 74. If not, 

40 the contract 26 is abandoned at step 76. 

[0099] An example of a negotiation discipline 28 per 
step 68 of Figure 6 is presented in Figure 7. This ne- 
gotiation discipline 28 is described as a "round robin" 
discipline, in that each participant 24 successively, has 

45 the opportunity to review a contract 26 and either accept 
to revise it. This process is repeated for a finite number 
of rounds. Once all participants 24 have accepted the 
contract 26, it is executed. 

[0100] The contract 26 will pass through the hands of 
so each participant 24 once per round, with the number of 
rounds predetermined. If a mutually acceptable contract 
26 is not negotiated within the predetermined number 
of rounds, the negotiation fails. 

[0101] The round robin negotiation begins at step 78 
55 where the Negotiation Manager 22 receives the partic- 
ipant 24 list and number of rounds generated internally, 
and the Initial contract 26 created by the Pint User's 
Agent 18. In the open concept of the invention, it is not 
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necessary for the negotiation discipline 28 routine to re- 
side in the Negotiation Manager 22 itself. This would al- 
low any entity of the negotiation to provide a negotiating 
discipline 28, or even to request a negotiating discipline 
28 provided by a third party. 

[0102] The next participant 24 in the negotiation is 
identified at step 80, and the contract 26 is transmitted 
to the next participant 24 at step 82. This participant 24 
will process the contract 26 in a manner that will be de- 
scribed with respect to Figures 6 through 9, and return 
the contract 26 to the Negotiation Manager 22 at step 
84. 

[0103] If the negotiation is not successful, it is deter- 
mined whether all participants 24 have been queried in 
the given round at step 86. If not, then control returns to 
step 80 so that the next participant 24 in the round may 
be identified. and queried. As the contract 26 identifies 
each participant 24 in the negotiation, it is straightfor- 
ward to tag or identify whether a participant 24 has re- 
viewed the current contract 26, and whether a partici- 
pant 24 has accepted a given contract 26. Such meth- 
ods of identification would be known to one skilled in the 
art. 

[01 04] At step 88, a determination is made whether a 
contract 26 has been successfully negotiated. As de- 
scribed above, the indication of acceptance would gen- 
erally be made by each participant setting a bit or flag 
in the contract 26, or by adding a cryptographic signa- 
ture before returning the contract 26 to the Negotiation 
Manager 22. This would require each of the participants 
24 to have reviewed and approved of the current con- 
tract 26. 

[0105] Preferably, a contract 26 could be accepted 
that a participant 24 has not yet reviewed, provided that 
it is more favourable to that participant 24 than one 
which it has already irrevocably approved. For example, 
if the First User's Agent 18 has approved a contract 26 
for 5 minutes at a constant bit rate of 10Kb/s for a cost 
of 5 cents per minute, which is to be irrevocable for a 
one minute period, and a contract 26 is subsequently 
negotiated for 5 minutes at a constant bit rate of 10 kb/ 
s at a cost of 4 cents per minute, then the participant 24 
would be considered to have already approved the more 
favourable contract 26, provided it is negotiated within 
the one minute irrevocable period. 
[0106] If the contract 26 has been successfully nego- 
tiated, the completed contract 26 is returned to the Ne- 
gotiation Manager 22 at step 90 for execution. 
[01 07] If the contract 26 has not been successfully ne- 
gotiated, then it is determined whether further rounds 
should be executed in attempting to negotiate a contract 
26, at step 92. If further rounds are necessary, control 
returns to step 80. If all of the predetermined rounds 
have been executed and a successful contract 26 had 
not been identified at step 88 then the negotiation is con- 
sidered to have failed, and the incomplete contract 26 
is returned to the Negotiation Manager 22 at step 94, 
along with a failure indication. 



[0108] Operation of the preferred embodiment of the 
Telecommunication Network's Agent 20 and First User's 
Agent 18 will now be described with respect to Figures 
8 and 9, respectively. Before describing the functionality 

5 of these agents, some preferred modes of implementa- 
tion common to both agents, will be described. 
[0109] Firstly, it is intended that Telecommunication 
Network's Agent 20 and First User's Agent 18 be imple- 
mented using software "agents" customized to their re- 

10 spective users, rather than generic software algorithms. 
Of course, the broad invention may be practised with 
generic software rather than agents, though with corre- 
sponding tradeoffs in functionality and flexibility. 
[0110] Secondly, although described herein with re- 

*5 spect to flow charts with successive steps, it is under- 
stood that the software agents will generally remain res- 
ident in the memory of a computer or telephony device, 
in an idle state. This will allow the agent to detect an 
incoming request for communication. 

20 [0111] Thirdly, in the preferred embodiment, it is in- 
tended that the Telecommunication Network's Agent 20 
and First User's Agent 18 be implemented using Java 
or C-m- based programming languages. The advantag- 
es of using Java would be clear to one skilled in the art, 

25 such as the current widespread use, particularly with re- 
spect to web browsers and other Internet based appli- 
cations, generally universal standards, and facility for 
"sandbox" security. Clearly, the invention is not limited 
by the use of such programming languages. 

30 [0112] The "sandbox" approach to security is one in 
which an applet is only allowed to operate within certain 
bounds (the sandbox). This constrained runtime envi- 
ronment prevents applets from accessing and altering 
unauthorized areas, or performing otherwise harmful 

35 operations. In Java applications, a special class called 
the Applet Security Manager performs this enforcement. 
For example, the Security Manager may prevent applets 
from reading or writing files to the Client's hard disk or 
establishing network connections except to the server 

40 that the applet came from. 

[01 13] As noted above, Figure 8 describes the oper- 
ation of a Telecommunication Network's Agent 20 in a 
preferred embodiment of the invention. Steps 38, 40, 42, 
44 and 46 would be implemented functionally in the 

45 same manner as those described with respect to the 
broad embodiment of Figure 4 above. 
[01 14] In the preferred embodiment, the Telecommu- 
nication Network's Agent 20 monitors the state of the 
network resources available and predicts expected us- 

50 age, so that it may make appropriate decisions required 
the acceptability of incoming contracts 26, and the gen- 
eration of outgoing contracts 26. 

[01 15] In the preferred embodiment, the Telecommu- 
nication Network's Agent 20 determines at step 96 
55 whether data on the state of the network is recent 
enough to allow correct decisions to be made, or wheth- 
er the data should be updated. If the determination has 
been made that new data are required, the new data are 
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obtained at step 89. 
[0116] The network data will comprise at least two 
types: internal and external. Internal data will consist 
generally of the current loading of closely held resourc- 
es, such as central processor units (CPUs) and memory, 5 
and the known obligations to provide telecommunica- 
tion services. These data are very easy to monitor as all 
access and management is under the control of the 
Service Provider. Generally, these data may be updated 
on a continuous or real time basis. io 
[0117] External data is more difficult to obtain and to 
predict, as it considers resources that are underthe con- 
trol of other Service Providers. Because administration 
of these services are beyond the reach of the Telecom- 
munication Network's Agent 20, it is necessary to query is 
the availability and quality on a regular basis, such as 
on a periodic basis determined by time or traffic. For ex- 
ample, it could be required that the network data be up- 
dated every minute or more frequently, or with every 
tenth call. 20 
[0118] In the preferred embodiment of the invention, 
the internal data may be monitored on a continuous ba- 
sis by recording the current loading and future obliga- 
tions. The external data is to be updated when a new 
call is received and a predetermined time period has ex- 25 
pired. 

[0119] Updating of the external data may be per- 
formed in a number of manners. For example, sample 
packets could be directed to pass through targeted tel- 
ecommunication networks or entities, and the perform- 30 
ance measured. In the preferred embodiment, requests 
will be transmitted to Service Providers requesting op- 
erational data to be returned. The onus will be on the 
Service Providers to forward data promptly, in order to 
remain as acceptable providers to the Telecommunica- 35 
tion Network's Agent 20. 

[0120] As both the Telecommunication Network's 
Agent 20 and First User's Agent 18 may be operable to 
monitor the performance during a communication, Serv- 
ice Providers will be forced to be honest with their offers, *o 
or clients and other Service Providers will refuse to use 
their services. 

[0121] In the preferred embodiment, the Telecommu- 
nication Network's Agent 20 will provide standard asyn- 
chronous transfer mode (ATM) services that have been 
chosen to describe the requirements of known applica- 
tions: 

1 . Constant Bit Rate (CBR) is intended to model 
standard voice telephony but is wasteful of band- so 
width. CBR is straightforward in definition, setting 
bandwidth with a given peak cell rate (PCR). The 
User also defines the tolerable cell delay variation 
(CVDT), which he expects to smooth out with buff- 
ering at the destination. Cell transfer delay (CTD), 55 
cell lost ratio (CLR) and peak-to-peak delay varia- 
tion (CDV) are specified by the network as its quality 
of service (QoS). Users would expect to pay by the 



20 
minute. 

2. Real-time Variable Bit Rate (rt-VBR) allows 
bursts up to a peak cell rate and maximum burst 
size (MBS) and guarantees cell transfer delay 
(CTD) and its tolerable variation (CD VT) at a spec- 
ified sustainable cell rate (SCR). This is a preferred 
mode for modern telephony. Users would probably 
still expect to pay by the second. 

3. Non-real-time Variable Bit Rate (nrt-VBR) does 
not guarantee CTD, and is more appropriate for a 
web browser application. Users would likely expect 
to pay by the minute, but would probably want a dis- 
count for slow packets. 

4. Unspecified Bit Rate (UBR) is basically best-ef- 
fort and models the current Internet service. UBR 
actually does specify peak ceil rate, but not a sus- 
tainable cell rate. Users might expect to pay by the 
megabyte. 

5. Available Bit Rate (ABR) specifies a minimum cell 
rate (MCR) as well as the peak, and the network 
uses back-pressure to control the flow. The network 
sends "resource management" cells to the source 
to allow it to adapt to the capacity available. Users 
might expect to pay by the minute for the minimum 
cell-rate and to pay a slight premium when rates are 
high, or to pay for premium service but get a dis- 
count when forced back down to the minimum rate. 
This mechanism should be able to get the best uti- 
lization out of the network when users have sophis- 
ticated rate-adaptive coders, and may be optimal 
for video telephone. 

[0122] As noted above, Figure 9 describes the oper- 
ation of a First User's Agent 18 in a preferred embodi- 
ment of the invention. Steps 48, 50, 52, 54 and 56 would 
be implemented functionally in the same manner as 
those described with respect to the broad embodiment 
of Figure 5 above. 

[01 23] Although the First User's Agent 18 and the Tel- 
ecommunication Network's Agent 20 are functionally 
similar with respect to the broad implementation, the fo- 
cus is quite different in the preferred embodiment. The 
focus of the Telecommunication Network's Agent 20 is 
on the state and predictability of the Telecommunication 
Network's 16 resources, while the focus of the First Us- 
er's Agent 18 is on the requirements of the First User 
Interface 12. The First User's Agent 18 may identify the 
resources that the First User Interface 12 has available, 
and determine the requirements of the User in a real 
time environment, before it can negotiate effectively on 
behalf of the First User Interface 12. 
[0124] For applications such as telephony and web- 
surfing, it is preferred that the First User's Agent 18 com- 
municate with the User via a graphic user interface 
(GUI) in a windows environment. It is preferred that this 
GUI be presented to the User as a webpaga which may 
be edited using a standard web browser. Techniques for 
developing such an interface with the functionality of the 
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invention are well known in the art. Other applications, 
such as remote surgery, may have First User require- 
ments embedded or "hardwired" into the First User's ap- 
plication program. 

[0125] At step 100 of Figure 9, the First User's Agent 
18 obtains information on the hardware resources and 
preferences of the First User Interface 12. Information 
regarding the hardware resources may be collected 
manually, whereby the User inputs the relevant data in 
response to prompts from the First User's Agent 18, but 
preferably is collected by the First User's Agent 18 from 
the operating system when the First User Interface 12 
is powered up. This information would include data such 
as the speed of the microprocessor, memory capacity 
and access time, operating system environment, mo- 
dem software and hardware. Methods of performing 
such tasks are well known in the art. 
[0126] User preferences are generally input manually, 
preferably through a graphical user interface and stored 
on the local computer. As well, the User Agent software 
may be provided with default values for parameters 
such as latency and speed. Details on such preferences 
are given herein below. 

[0127] The First User's Agent 18 then resides in an 
idle mode at step 102, awaiting either a request to ac- 
cept an incoming call, or a request from the local user 
to generate an outgoing request. If a request arrives to 
accept an incoming call, then control passes to step 50, 
which executes as described above with respect to Fig- 
ure 5. 

[0128] If a request is received from the User or a User 
program to initiate negotiation of a new communication, 
control passes to step 104, where the necessary data 
is collected to create an initial contract 26. Typically, this 
initial contract 26 would be created by the First User's 
Agent 18 querying the User for the following information: 

1 . A destination, orcalled party, such as Second Us- 
er interface 14 in Figure 1 

2. An application, such as videoconferencing, voice 
communication, web browsing or email. 

The First User's Agent 18 would have default pa- 
rameters associated with most of these applica- 
tions, as described briefly with respect to the ATM 
modes above, including minimum acceptable costs, 
latencies and speed. These defaults could be mod- 
ified by the User, or new modes created. If a partic- 
ular application is unknown to the First User Agent, 
then the User could be queried for default parame- 
ters with the First User Agent storing these param- 
eters for future reference. For example, a User may 
wish to have more than one default mode for voice 
communication: toll quality for business use and low 
quality voice for personal or peak period use. A 
skilled technician would be capable of implement- 
ing software to perform such functions. 

3. Manual or automatic confirmation of acceptance 
of a contract 26 negotiated by the First User's Agent 
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4. Coordination of costs. For example, costs may 
be assessed to the calling party, called party (re- 
versing the charges, or toll free 1 -800 telephony 

5 services), shared billing, or pay per use (such as 
1 -976 telephony services). 

5. Preference not to allow non-revocable contracts 
26. 

6. Preferences as to particular Service Providers to 
10 contact and negotiate with. 

7. Preferences as to which Negotiation Manager 22 
or negotiating discipline 28 is to be used and a URL 
address or location on a local disk where they may 
be found. 

15 

[0129] On the basis of the queried information, and in 
combination with the knowledge of the User Interface 
12 collected at step 100, the First User's Agent 18 cre- 
ates an initial contract 26 at step 104, which it transmits 

20 to the preferred Service Provider at step 106. The First 
User's Agent 1 8 then awaits a contract 26 to be returned 
from the Negotiation Manager 20 at step 48. 
[0130] The balance of the routine executes in the 
same manner as that described with respect to Figure 

25 5 above until step 108 is reached. At step 1 08, the user 
may exit the routine or return to step 102 to continue 
monitoring for either a request for a new communication 
to be initiated, or a new contract to be received. 
[0131] The invention may be applied with a broad 

30 range of optional functionality, which would be clear to 
one skilled in the art from the teachings herein. One 
such option would be the flexibility to halt and re-nego- 
tiate terms during a communication. This would allow, 
for example, a Service Provider to make his fastest com- 

35 munication lines available for a reduced price on the 
condition that the lines can be revoked if a higher paying 
customer wishes to obtain the line. Agreeability to such 
interruptions would have to be approved of during the 
initial negotiation, but this would allow ail participants an 

40 extra degree of flexibility that is not offered by existing 
systems. 

[0132] Another option would be the handling of recur- 
sive negotiations by the software agents themselves 
rather than the Negotiation Manager 20. Rather than al- 

45 lowing the Negotiation Manager 20 to distribute a con- 
tract 26 to Network Entities that it identifies, a First Us- 
er's Agent 18 may wish to identify Local Network sub- 
Entities, such as other Service Providers, that it wishes 
to participate in the negotiation. This would allow the 

so First User's Agent 18 to screen groups of participants 
from one another. Similarly, the Network Agent may 
have Network sub- Entities that it wishes to have partic- 
ipate in the negotiation, but which it wishes to screen 
from other parties in the negotiation. In both cases, the 

55 participant can receive the contract 26, send it to the 
sub-participant and receive the sub-participants re- 
sponse. The pa/ticipant may wish to modify the contract 
26 by adding or removing information before sending it 
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to the sub-participant, and modifying the sub-partici- 
pant's response before sending it to the Negotiation 
Managers 20. 

[0133] In addition to the "round robin" negotiating dis- 
cipline 28 described herein above, it is expected that a 
variety of other negotiating disciplines 28 would be 
made available by the Negotiation Managers 20 or third 
parties. These would include: 

1 . Bid and Ask - Each entity is allowed to make of- 
fers which others may accept at any time. A less 
structured discipline than the round robin discipline, 
as entities may introduce new bids at any time. 

2. Bluffing - Only negotiating with regard to certain 
parameters and keeping others secret. This allows 
entities to bluff as to their requirements or resources 
in an attempt to negotiate better terms. For exam- 
ple, a Service P rovider may not want to disclose that 
his resources are not being used, as a User might 
respond by holding out for a lower price. 

3. Poker - A Service Provider may allow a number 
of Users to bid on services simultaneously and pro- 
vide services to those Users who reach a certain 
level in the negotiation. For example, a Service Pro- 
vider may have 10 identical communication units 
available and start negotiation with 20 Users bid- 
ding on various numbers of units. As the price rises, 
Users will drop out of the negotiation, and the Serv- 
ice Provider will settle once he has Users bidding 
on the 10 units or less. This negotiating discipline 
more would be useful in the sale of commodity serv- 
ices, such as the availability of a communication line 
for a predetermined time period, rather than on a 
per call basis. 

4. Reverse Auction - A Service Provider may start 
a negotiation with multiple Users, at a high price and 
lower that price until a User accepts. This discipline 
would also be useful in the sale of commodity serv- 
ices. 

[0134] While particular embodiments of the present 
invention have been shown and described, it is clearthat 
changes and modifications may be made to such em- 
bodiments without departing from the true scope and 
spirit of the invention. 

[0135] Although the detailed operation has been de- 
scribed with respect to method steps, clearly the inven- 
tion may be embodied by a combination of software and 
hardware. The method steps may be executed by a 
computer processor or similar device suitably pro- 
grammed, or may be executed by an electronic system 
which is provided with means for executing these steps. 
Similarly, an electronic memory means such as a com- 
puter diskette, CD-Rom. Random Access Memory 
(RAM) and Read Only Memory (ROM) may be pro- 
grammed with coding to execute such method etepe. Ae 
well, electronic signals representing these method steps 

may also be transmitted via a communication network. 



[0136] The sets of executable machine code repre- 
sentative of the method steps of the invention may be 
stored in a variety of formats such as object code or 
source code. Such code is described generically herein 

5 as programming code, or a computer program for sim- 
plification. This executable code may also be transmit- 
ted as an electronic signal over communication links. As 
well, the executable machine code may be integrated 
with the code of other programs, implemented as sub- 

10 routines, by external program calls or by other tech- 
niques as known in the art. 

[0137] It is understood that as communication net- 
works become more flexible and powerful, the tradition 
definitions of servers, routers, computers, telephones 

is and other hardware components are becoming less and 
less clear. These terms have been used herein to sim- 
plify the discussion and do not strictly limit the invention 
to the former definitions of such hardware. For example, 
a cellular telephone with Internet access may implement 

20 the invention by being supplied with a software agent in 
read only memory. Such a telephone would clearly not 
have the traditional limitations associated with the term 
"telephone". 

[0138] Similarly, existing telephony providers could 
25 modify their routing equipment to apply the invention in 
a broad range of manners, including adding on the new 
operability as stand-alone equipment, or modifying their 
existing equipment accordingly. In either situation, it 
would not be expected that the actual implementation 
30 would read literally on the method as outlined herein, 
but that one skilled in the art would be capable of imple- 
menting the invention is such applications from the de- 
scription of the invention herein. 
[0139] As well, the order and details of the method 
35 steps could easily be modified and still realize the ben- 
efits of the invention. Such modifications would be clear 
to one skilled in the art. The embodiments as presented 
herein are intended to be illustrative and not limiting. 

40 

Claims 

1. A user interface (12) comprising: 

45 a user-input hardware resource for receiving an 

input of a communication from a user; 
a user-output hardware resource forpresenting 
an output of said communication to said user; 
a computer processing hardware resource for 

so executing a software application that process- 

es said input from said user-input hardware re- 
source and processes said output to said user- 
output hardware resource; and 
a connection means for connecting said com- 

55 puter processing hardware resource to a sec- 

ond user interface (14) via network (16), eaid 
connecting means further for connecting to at 
least one computer processor and electronic 
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memory means that is operable to execute a 
first set of programming code (1 8) for determin- 
ing said user interface's (12) requirements for 
conducting said communication with said sec- 
ond user interface (14), said first set of pro- 5 
gramming code (18) further for negotiating 
terms of said communication with a second set 
of programming code (20) that determines 
available network resources of said network 
(16), the negotiation between the first set of 10 
programming code (18) and said second set of 
programming code (20) managed by a third set 
of programming code(22) that bases said ne- 
gotiation on a trusted negotiated discipline (28). 
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2. The user interface (12) of claim 1 wherein said trust- 
ed negotiating discipline is selectable by a user of 
said first user interface (12) from a plurality of ne- 
gotiating disciplines (28); and/or 

wherein said requirements include the availa- 
ble hardware resources of said first user inter- 
face (12); and/or 

wherein said requirements include the network 
resources needed by an application executing 
on said user interface (12); and optionally 
wherein said application is voice telephony. 

3. The user interface (12) of claim 1 wherein require- 
ments include the costs that are to be assessed to 
said first user interface (12) during said communi- 
cation; and/or 

wherein said available network resources in- 
clude presently available network resources; 
and/or 

wherein said available network resources in- 
clude a cost of the network resources to be con- 
sumed during said communication; and/or 
wherein said available network resources in- 
clude a prediction of network usage during said 
communication; and/or 

wherein said first set of programming code is 
implemented using a software agent (18) pro- 
grammed with instructions that represent the 
interests of said first user interface (12); and/or 
wherein said third set of programming code is 
implemented as a negotiation manager soft- 
ware agent (22); optionally 
wherein said second set programming code is 
implemented as a single network software 
agent (20). 



4. The user interface (1 2) of claim 1 , wherein said sec- 
ond set of programming code is implemented as 55 
multiple network software agenta (20), eaoh net- 
work software agent being respective to a different 
telecommunication service provider; and/or 
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wherein said communication is voice telepho- 
ny; and/or 

wherein said network (16) is an ATM network; 
and/or 

wherein said negotiating discipline (18) in- 
cludes at least one of a round robin, bid-and- 
ask, bluffing, poker and a reverse auction; and/ 
or 

wherein said negotiating discipline (18) termi- 
nates said negotiation if said negotiations fail 
to reach an agreement within a predetermined 
period of time. 

5. A telecommunication network (20) comprising: 

an interconnection means to connect a first us- 
er interface (12) with a second user interface 
(14); said interconnection means operable to 
consume a variable amount of network re- 
sources; 

a computer processing hardware resource for 
executing a software application that process- 
es a communication between said first user in- 
terface (1 2) and said second user interface (1 4) 
through said interconnection means; 
a connection means for connecting said com- 
puter processing hardware resource to at least 
one computer processor and electronic memo- 
ry means that is operable to execute a network 
set of programming code (20) for determining 
an available amount network resources, said 
network set of programming code (20) further 
for negotiating terms of said communication 
with a second set of programming code (18) 
that determines requirements for said commu- 
nication of at least said first user interface (1 2), 
the negotiation between said network set of 
programming code (20) and said second set of 
programming code (1 8) managed by a third set 
of programming code (22) that bases said ne- 
gotiation on a trusted negotiating discipline 
(28). 

6. The telecommunication network (16) of claim 5, 
wherein said trusted negotiating discipline is se- 
lectable by a user of said first user interface (12) 
from a plurality of negotiating disciplines (28); and/ 
or 

wherein said requirements include the availa- 
ble hardware resources of said first user inter- 
face (12); and/or 

wherein said requirements include the network 
resources needed by an application executing 
on said user interface (12); and/or 
wherein said application ie voioe telephony; 
and/or 

wherein requirements include the costs that are 
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to be assessed to said first user interface (12) 
during said communication; and/or 
wherein said available network resources in- 
clude presently available network resources; 
and/or 5 
wherein said available network resources in- 
clude a cost of the network resou rces to be con- 
sumed during said communication. 

7. The telecommunication network (16) of claim 5, io 
wherein said available network resources include a 
prediction of network usage during said communi- 
cation; and/or 

wherein said first set of programming code is is 
implemented using a software agent (18) pro- 
grammed with instructions that represent the 
interests of said first user interface (12); and/or 
wherein said third set of programming code is 
implemented as a negotiation manager soft- 20 
ware agent (22); and/or 

wherein said second set programming code is 
implemented as a single network software 
agent (20); and/or 

wherein said second set of programming code 25 
is implemented as multiple network software 
agents (20). each network software agent be- 
ing respective to a different telecommunication 
service provider; and/or 

wherein said communication is voice telepho- 30 
ny; and/or 

wherein said network (16) is an aTM network; 
and/or 

wherein said negotiating discipline (18) in- 
cludes at least one of a round robin, bid-and- 35 
ask, bluffing, poker and a reverse auction; and/ 
or 

wherein said negotiating discipline (18) termi- 
nates said negotiation if said negotiations fail 
to reach an agreement within a predetermined 40 
period of time. 

8. An apparatus for managing a network comprising: 

a connection means to connect a telecommu- *s 
nication network (16) and to connect to a first 
user interface (12) that is seeking to establish 
an interconnection with a second user interface 
(14) via said telecommunication network (16); 
and so 
a computer processor and electronic memory 
means attached to said connection means that 
is operable to execute a negotiation-manage- 
ment set of programming code (22) that man- 
ages a negotiation between a first-user inter- 55 
face set of programming code (18) and a net- 
work set of programming code (20), said first- 
user interface set of programming code for de- 
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termining said first user interface's require- 
ments for communicating with said second user 
interface (14) and representing said first-user 
interface's (12) interests during said negotia- 
tion, said network set of programming code (2) 
for determining available network resources 
and representing said set network's (16) inter- 
ests during said negotiation, said negotiation- 
management set of programming code (22) 
basing said negotiation on a trusted negotiating 
discipline (28). 

9. The apparatus according to claim 8, wherein said 
connection means is further operable to connect to 
said second user interface and said negotiation- 
management set of programming code (22) man- 
ages said negotiation so as to include a second-us- 
er interface set of programming code (1 4) for deter- 
mining said first user interface's requirements for 
communicating with said first user interface (12) 
and representing said first-user interface's (12) in- 
terests during said negotiation; and/or 

wherein said trusted negotiating discipline is 
selectable by a user of said first user interface 
(12) from a plurality of negotiating disciplines 
(28); and/or 

wherein said requirements include the availa- 
ble hardware resources of said first user inter- 
face (12); and/or 

wherein said requirements include the network 
resources needed by an application executing 
on said user interface (12). 

10. The apparatus according to claim 8, wherein said 
application is voice telephony; and/or 

wherein said requirements include the costs 
that are to be assessed to said first user inter- 
face (12) during said communication; and/or 
wherein said available network resources in- 
clude presently available network resources; 
and/or 

wherein said available network resources in- 
clude a cost of the network resources to be con- 
sumed during said communication; and/or 
wherein said available network resources in- 
clude a prediction of network usage during said 
communication; and/or 

wherein said first user-interface set of program- 
ming code is implemented using a software 
agent (18) programmed with instructions that 
represent the interests of said first user inter- 
face (12); and/or 

wherein said network-management set of pro- 
gramming code is implemented as a negotia- 
tion manager software agent (22); and/or 
wherein said network set programming code is 
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implemented as a single network software 
agent (20); and/or 

wherein said network set of programming code 
is implemented as multiple network software 
agents (20), each network software agent (20) 5 
being respective to a different telecommunica- 
tion service provider. 

11. The apparatus according to claim 8, wherein said 
communication is voice telephony; and/or 10 

wherein said network (16) is an ATM network; 
and/or 

wherein said negotiating discipline (18) in- 
cludes at feast one of a round robin, bid-and- is 
ask, bluffing, poker and a reverse auction; and/ 
or 

wherein said negotiating discipline (18) termi- 
nates said negotiation if said negotiations fail 
to reach an agreement within a predetermined 20 
period of time; and/or 

wherein said negotiation is initiating said com- 
munication; and/or 

wherein said communication is ongoing and 
said negotiation is for modifying terms of said 25 
existing communication. 



terminating said negotiating if any one of said 
offers and counteroffers fail to converge ac- 
cording to said negotiation discipline (28); and 
notifying said first set of programming code (1 8) 
and said second set of programming code (20) 
of terms of any one of said offers and counter- 
offers that converge according to said negoti- 
ating discipline (28). 

13. The computer-implemented method according to 
claim 1 2, wherein said offer is for initiating said com- 
munication; and/or 

wherein said communication is ongoing and said of- 
fer is for modifying terms of said existing communi- 
cation. 



12. A computer-implemented method for negotiating 
terms of communication between a first user inter- 
face (1 2) and a second user interface (14) connect- 30 
ed by a telecommunications network (16), said 
method comprising the steps of: 

receiving, from a first set of programming code 
(18) associated with said first user interface 35 
(1 2), an offer for said terms of communication, 
said first user interface's (12) offer including 
said first user interface's (12) requirements for 
communicating with said second user interface 
(14) through said network (16); verifying said *o 
first user interface's (12) offer conforms with a 
trusted negotiation discipline (28); 
presenting said first user interface's (12) offer 
to a second set of programming code (20) as- 
sociated with said network (1 6) if said first user 45 
interface's (12) offer conforms with said disci- 
pline (28); 

receiving, from said second set of programming 
code (20); another offer for said terms of com- 
munication, said another offer including at least so 
said network's (1 6) available resources for said 
communication, and including a modification of 
said first user interface's (12) offer; 
returning said another offer to said first set of 
programming code (18) if said another offer 55 
conforms with said discipline (28); 
repeating the foregoing steps If said offers con- 
form with said discipline (28); 
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